The Lightweight Directory Access Protocol (“LDAP”) is a standard computer networking protocol for querying and modifying entries in a database. The basic protocol is defined in a group of Internet Engineering Task Force (“IETF”) Request for Comments (“RFC”) documents; various aspects of the current version of the protocol (version 3) are described in RFCs listed in the “LDAP Technical Specification Road Map” (RFC4510, published June 2006). The databases reachable through LDAP may contain any sort of data, but most commonly contain identity and contact information for people and organizations.
LDAP presents a hierarchical view of the data in a database. Records are presented as a tree of entries like that shown in FIG. 2, element 200. An entry 210, detailed in FIG. 2A, is identified by a Distinguished Name (“DN”) 211, which is made up of a Relative Distinguished Name (“RDN”) 212—an unordered set of one or more Attribute Value Assertions (“AVAs”)—and the DN 213 of the entry's parent. The AVAs correspond to one or more of the attributes 214 in the entry (the “distinguished attributes”). Attributes (both distinguished 214 and ordinary 215) consist of an attribute description 216 (an attribute type with zero or more options), plus one or more values 217.
An LDAP server responds to commands from an LDAP client. For example, a client may create a new entry, delete an entry, rename an entry, modify an entry, or (most commonly) retrieve the attributes in an entry. In a basic LDAP implementation, identical data elements in two LDAP entries are completely independent copies of each other. Thus, for example, even if two employees work at the same facility of an organization, the “postalAddress” attributes of their records are independent, so if the facility is moved to a different location, each employee's LDAP record must be updated independently to show the new address.
Virtual LDAP attributes have been developed to reduce the effort required to make changes to groups of data records, and to prevent errors that may occur when the same change is to be made to many records. Thus, for example, an LDAP server might store an entry 220 in the hierarchical tree (or elsewhere), the entry containing information similar to that detailed in FIG. 2B. Attribute 225 is a virtual attribute to be added to an LDAP response prepared for any client that retrieves an employee's entry. Such a response is detailed in FIG. 2C: an LDAP query for the record identified by DN:cn=Alice, dc=example, dc=com might retrieve attributes 230 that are actually present in the requested entry 210, along with a virtual postalAddress attribute 240 copied from record 220 at DN:operation=QueryEmployee, dc=example, dc=com. A client receiving the query response would see the postalAddress attribute 240 as part of Alice's LDAP record. In some virtual attribute implementations, it is not possible for the client to distinguish between ordinary and virtual attributes provided with an LDAP response. Note that virtual attribute source data need not be stored in the same hierarchy as other LDAP data, nor even in the same database. However, common storage may permit the use of existing LDAP administrative tools to monitor and maintain the database.
Virtual attributes are simple and effective, and can be deployed without requiring changes to LDAP clients (which can receive and process the virtual attributes identically to ordinary attributes). However, virtual attributes can complicate administration and troubleshooting of an LDAP database. Further refinements to virtual LDAP attributes may improve this situation.